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Hon. Commissioner for Patents 
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BRIEF ON APPEAL 

Dear Sir: 

This appeal arises from a final decision by the Examiner in the Office Action, dated 
October 19, 2004. The final decision was in response to arguments filed on June 28, 
2004, in response to an earlier office action, mailed April 26, 2004. 



Appellants response, filed on December 1 4, 2004 under 37 CFR 1 . 1 1 6, to the final 
decision offered to cancel claims 34-37 in an effort to remove issues for appeal and 
to correct previously undetected grammatical informalities in claims 4, 17, 23, 24 
and, 31 . However, the Advisory Action dated February 3, 2005 not only refused 
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entry of the offered claim cancellations and claim amendments, but indicated the sua 
sponte rejection of previously allowed claims 20-33 without explanation. Appellants' 
attempts to clarify the potential clerical error in the Advisory Action with the Examiner 
have been, as yet, unsuccessful and so the related issues are also included in this 
Appeal. 

Appellants submit this Brief on Appeal in triplicate, including payment in the amount 
of $500.00 to cover the fee for filing the Brief on Appeal. Appellants respectfully 
request consideration of this appeal by the Board of Patent Appeals and 
Interferences for allowance of the present patent application. 

Real Party in Interest : 

This application is assigned to BEA Systems, Inc., having a principal place of 
business at 2315 North First Street, San Jose, California 95131 . The assignment is 
pending recordation at the United States Patent and Trademark Office. 

Related Appeals and Interferences : 

To the best of Appellants' knowledge, there are no related appeals or interference 
proceedings currently pending, which would directly affect or be directly affected by 
or have a bearing on the Board's decision in this appeal. 

Status of Claims : 

Claims 1-16 and 20-33 are rejected and are under appeal. Claims 34-37 were 
cancelled. Claims 1-37 were pending and claims 1-16 and 34-37 were rejected in 
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the Final Office Action dated October 19, 2004. Claims 20-33 were rejected in the 
Advisory Action without explanation. On entry of the offered amendments and 
cancellations to reduce the number of issues on appeal, claims 1-33 are pending, 
and are reproduced, as pending, in Appendix A. 

Status of Amendments : 

To reduce the number of potential issues on appeal, amendments are being offered 
for claims 4, 17, 23, 24 and, 31 in conjunction with cancellation of claims 34-37. The 
offered amendments correct previously undetected grammatical informalities. Since 
claims 4, 17, 23, 24 and, 31 were previously pending, and no new matters are being 
introduced, no new searches are required, nor are new issues being raised. 

An after final response {Response under 37 CFR §1.1 16) was filed on December 
14, 2004. Claims 4, 17, 23, 24 and, 31 were amended to correct previously 
undetected informalities and claims 34-37 were canceled after the final Office action. 
The cancellations and amendments were offered to reduce the number of issues on 
appeal. A Notice of Appeal was submitted on January 19, 2004. The Advisory 
Action dated February 3, 2005 rejected entry of the proposed amendments to claims 
4, 17, 23, 24 and, 31 and rejected the offered cancellation of pending claims 34-37. 

Summary of the Invention : 

As stated in the first paragraph on page 1 of the specification of the instant 
application, the invention relates to concurrently hosting application services with 
multiple versions of the hosting services. Embodiments of the invention relate to an 
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application service provision apparatus having an application service provision 
runtime library with multiple versions. In addition, at least one embodiment of the 
invention relates to a shared resource consumer and a method of operation of the 
shared resource consumer. Embodiments of the invention further relate to a method 
of operation of an apparatus having a shared resource monitor. 

Appellant explained on page 6 of the specification, line 10, that, referring now in 
detail to figure 1 of the drawing, there is a block diagram illustrating an overview of 
the present invention, including an application service provision apparatus equipped 
with a dispatching and a shared resource monitoring function, in accordance with 
one embodiment. The application service provision apparatus (108) hosts a number 
of application services, e.g. (116i) and (116n), on behalf of their developers. The 
application service provision apparatus (108) is advantageously equipped with 
different versions of runtime support, also referred to as the runtime library, e.g. 
(114i) and (114n). Clients (102a) and (102b) access these various application 
services, e.g. (116i) and (116n), through networking fabric (106), using various 
known messaging protocols (e.g. HTTP) signaled in accordance with various known 
communication protocols (e.g. TCP/IP). 

Appellant further explained on page 7 of the specification, line 1 , that the application 
service provision apparatus (108) includes one or more resources shared by the 
application services (116*) and/or the functions of the runtime library (114*), e.g. 
memory resource (120). The application service provision apparatus (108) is also 
provided with a dispatcher function (110), and a shared resource monitor function 
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(118) to facilitate the current support of the multiple versions of runtime library, and 
efficient operation of the resources. One embodiment of the dispatcher function 
(110) includes an associated application and runtime (RT) library version mapping 
cache (112) and is employed to perform the dispatching function, i.e. routing of 
requests for service from clients (102a-102b) to selected ones of the application 
services being hosted. 

Appellant outlined on page 9 of the specification, starting on line 4, that, 

embodiments of the present invention effectuate the dispatcher function by 

loading the latest version of the runtime library (114n) at initialization of the 
application service provision apparatus, the latest version of the 
runtime library includes data associating an application with a required 
version of the runtime library; 

during operation, receiving by a dispatcher (110) a request for service for the 
application (202); 

in response, determining by the dispatcher (110) whether the required version 
of the runtime library used by the application is known to the dispatcher 
(204); and 

if the version of the runtime library required by the application is not known to 
the dispatcher, inquiring by the dispatcher of the latest version of the 
runtime library to learn of the required version of the runtime library 
(206). 

References Cited : 

U.S. Patent No. 6,332,168 {House et a/.), dated September 28, 1995; 
Issues Presented: 

I. Whether or not claims 1-16 are anticipated by House, et al. under 35 U.S.C. 
§1 02(e). 
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II. Whether or not previously allowed substantially unchanged claims 20-33 are 
properly rejected without fully and clearly stating the grounds of rejection. 

III. Whether or not proposed cancellation of claims 34-37 are properly refused. 

IV. Whether or not claims 20-33 are anticipated by House, et al. under 35 U.S.C. 
§1 02(e). 

Grouping of Claims: 

Claims 1,7, 9, 16, 17, 20, 23, 27, 30 are independent. Claims 2-6 depend on claim 
1 . Claim 8 depends on claim 7. Claims 10-15 depend on clajm 9. Allowed claims 
18 and 19 depend on allowed claim 17. Claims 21 and 22 depend on claim 20. 
Claims 24-26 depend on claim 23. Claims 28 and 29 depend on claim 27. Claims 
31-33 depend on claim 30. The patentability of claims 1-16 and claims 20-33 are 
separately argued. Therefore, claims 2-16 stand or fall with claim 1 but claims 20-33 
do not fall with claim 1 . 

Arguments : 

1. Rejection of claims 1-16 under 35 U.S.C. 51 02(e) was improper 
because House, et al. failed to teach each and every limitation 

As discussed in detail below, House failed to teach at least the required limitation of 
inquiring by the dispatcher of the latest version of the runtime library to learn 
of the required version of the runtime library as recited in claim 1. 
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It is well settled that anticipation under 35 U.S.C. §1 02(e) requires the disclosure in a 
signal piece of prior art to teach each and every limitation of a claimed invention. 
Electro Med. Sys. S.A. v. Cooper Life Sciences, 34 F.3d 1048, 1052, 32 USPQ2d 
1017, 1019 (Fed. Cir. 1994). More specifically, MPEP 2131 states, "TO 
ANTICIPATE A CLAIM, THE REFERENCE MUST TEACH EVERY ELEMENT OF 
THE CLAIM" and "a claim is anticipated only if each and every element as set forth 
in the claim is found, either expressly or inherently described, in a single prior art 
reference." Verdegaal Bros, v. Union Oil Co. of California, 814 F.2d 628, 631, 2 
USPQ2d 1051, 1053 (Fed. Cir. 1987). Thus, to anticipate the present invention, 
House must disclose every element recited in the pending claims. 
Claim 1 recites as follows: 

1 . In an application service provision apparatus having an application service 
provision runtime library with multiple versions, a method of operation comprising: 
loading the latest version of the runtime library at initialization of the 
application service provision apparatus, the latest version of the 
runtime library includes data associating an application with a required 
version of the runtime library; 

during operation, receiving by a dispatcher a request for service for the 
application; 

in response, determining by the dispatcher whether the required version of the 
runtime library used by the application is known to the dispatcher; and 

if the version of the runtime library required by the application is not known to 
the dispatcher, inquiring by the dispatcher of the latest version of the 
runtime library to learn of the required version of the runtime library . 

Accordingly, to achieve the desired inquiry of the latest version of the runtime library 
to determine the required version of the runtime library when the version is unknown 
to the dispatcher, claim 1 first requires the consultation of a runtime library as to what 
version of the runtime library an application needs. 
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In contrast, House fails to perform this required operation. Instead, House teaches 
that the RTSS links the application program to an appropriate Run Time Library 
version as specified in the APDB - and to a default version if there is no specification 
in the APDB. See at least col. 4, lines 35-40 and Figure 3. Figures 5 through 7 
teach of the RTSS 310 consulting the APDP 335 at the start of the system to obtain 
the description of the known runtime libraries, including LPA statements and CSA 
statements. The predominate balance of Figure 5 and most of Figure 6 merely 
describe loading the LPA language modules, building of Library Vectors and Library 
Vector Pointers. Figure 6 through Figure 7 show that when an application starts, the 
application asks the RTSS where the appropriate runtime libraries are. In response, 
the RTSS provides the application with the location of the appropriate runtime library 
(if known). 

Figure 8 shows, among other things, that if the runtime library is not known by the 
system, the RTSS will indicate that the application should use the default library. 
Neither Figure 9 nor Figure 10 contain any descriptive information explaining what 
the process should do if the runtime library version is unknown. Nowhere in House, 
including Figures 5-10, is there a discussion or teaching of an operation " inquiring by 
the dispatcher of the latest version of the runtime library to learn of the required 
version of the runtime library ." 

Therefore, for at least the reasons set forth above, Appellants submit that 
House does not anticipate Claim 1 under § 102(e). As such, Appellants submit that 
Claim 1 is in proper form for allowance and request that the rejection be removed. 
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As with Claim 1, Claims 7, 9, and 16 are similarly rejected under § 102(e) as 
anticipated by House. Appellants submit that Claims 7, 9, and 16 contain limitations 
similar to Claim 1 . Thus, for at least the reasons set forth above with respect to 
Claim 1 , Appellants believe that Claims 7, 9, and 16 are likewise in proper form for 
allowance. 

Claims 2-6, 8, and 10-15 depend on Claims 1, 7, and 9, respectively. Due at least in 
part on their dependency, Appellants submit that claims 2-6, 8, and 10-15 are 
likewise in proper form for allowance. 

2. Rejections of claims 20-33 failed to fully and clearly state the ground of 
rejection or designate the statutory basis for any ground of rejection 
and was thus improper under MPEP 707.07(d) 

MPEP 707.07(d) requires that "Where a claim is refused for any reason relating to 
the merits ... The examiner should designate the statutory basis for any ground of 
rejection by express reference to a section of 35 U.S.C. in the opening sentence of 
each ground of rejection." In the instant case, no statutory basis is provided for the 
rejection of previously allowed claims 20-33. Moreover, the Advisory Action only 
references previously rejected claim 1 . 

In view of the foregoing, Appellants respectfully submit that claims 20-33 are 
patentable over House as indicated by the Examiner in the final Office Action in the 
last paragraph on page 4 and the first paragraph on page 5. 
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In the alternative, Appellants respectfully urge the honorable Board to reverse the 
final rejection of the Primary Examiner in the Advisory Action and remand for further 
consideration in a first Office action on the merits of claims 20-33, so that the 
Appellants have opportunity to respond or clarify the subject matter included in 
claims 20-33. 

3. Whether or not proposed amendments are properly refused, including 
the offered cancellation of claims 34-37. 

Although MPEP 714.12 indicates that "once a final rejection ... has been entered in 
an application, applicant or patent owner no longer has any right to unrestricted 
further prosecution." This does not mean that no further amendment or argument 
will be considered. In fact, MPEP 714.12 clarifies that "any amendment that will 
place the application either in condition for allowance or in better form for appeal 
may be entered." In the instant case, Appellants assert that the offered 
amendments improve the claims as to form and reduce the number of issues on 
appeal. Thus the offered amendments are to be permitted after final action in 
accordance with 37 CFR 1 .1 16(b) which clearly indicates that "amendments may be 
made canceling claims". 

4. Whether or not claims 20-33 are anticipated by House, et al. under 35 
U.S.C. S102(e). 

As previously established, anticipation under 35 U.S.C. §1 02(e) requires that each 
and every element as set forth in the claim is found, either expressly or inherently 
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described, in a single prior art reference. Moreover, MPEP 2131 states, "to 
anticipate a claim, the reference must teach every element of the claim." 

Appellants agree with the Examiner's statement in the last paragraph on page 4 of 
the final Office Action that House "does not teach tracking by the resource 
consumers, identifying points in time where the allocations of the shared resource 
were last used, and making available the tracked usage information requested by the 
resource monitor to allow the resource monitor to be able to determine which of the 
allocated resources are to be released." 

Moreover, with respect to claims 23-26 and 30-33, Appellants further agree with the 
Examiners statement in the first paragraph on page 5 of the final Office Action that 
claims are allowable "for the same reasons discussed above with respect to claims 
17, 20, and 27. 

In the instant case, none of the references either show or suggest the features of 
claims 20, 23, 27, and 30. Claims 20, 23, 27, and 30 are, therefore, believed to be 
patentable over the art. The dependent claims are believed to be patentable as well 
because they all are ultimately dependent on claims 20, 23, 27, and 30. 
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The honorable Board is therefore respectfully urged to reverse the final rejection of 
the Primary Examiner. 

Respectfully submitted, 



KHF/cgm 

Date: March 21, 2005 

Schwabe Williamson & Wyatt, P.C. 
1420 Fifth, Suite 3010 
Seattle, WA 98101 

Tel: (206)622-1711 
Fax: (206) 292-0460 




Kyle H. Flihdt 
Reg. No. 42,539 
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1 . (Original): In an application service provision apparatus having an 
application service provision runtime library with multiple versions, a method of 
operation comprising: 

loading the latest version of the runtime library at initialization of the 
application service provision apparatus, the latest version of the runtime library 
includes data associating an application with a required version of the runtime 
library; 

during operation, receiving by a dispatcher a request for service for the 
application; 

in response, determining by the dispatcher whether the required version of 
the runtime library used by the application is known to the dispatcher; and 

if the version of the runtime library required by the application is not known to 
the dispatcher, inquiring by the dispatcher of the latest version of the runtime library 
to learn of the required version of the runtime library. 



2. (Original): The method of claim 1 , wherein said method further comprises the 
latest version of the runtime library informing the dispatcher which version of the 
runtime library is the required version of the runtime library, and the dispatcher 
caching the required version information. 



3. (Original): The method of claim 2, wherein said method further comprises the 
dispatcher routing the request of service to the application to handle if the 
dispatcher is informed by the latest version of the runtime library that the required 
version of the runtime library is the latest version itself. 



4. (Currently Amended): The method of claim 2, wherein said method further 
comprises the dispatcher determining whether the required version of the runtime 
library is loaded if the required version is an earlier version of the runtime library[[,]] 
and A if the required earlier version of the runtime library is not loaded, loading the 
required earlier version. 



5. (Original): The method of claim 4, wherein said method further comprises the 
dispatcher routing the request of service to the application to handle if the required 
earlier version of the runtime library is already loaded or upon loading the required 
earlier version of the runtime library. 



6. (Original): The method of claim 1 , wherein said method further comprises the 
dispatcher routing the request for service to the application to handle if the required 
version of the runtime library is known to the dispatcher. 
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7. (Original): In an application service provider apparatus having an application 
service provision runtime library with multiple versions, a method of operation 
comprising: 

inquiring with the latest version of the runtime library to identify the version of 
the runtime library required by an application whenever the required version is not 
known; and 

in response, the latest version of the runtime library responding with the 
required version. 

8. (Original): The method of claim 7, wherein the method further comprises 
loading the latest version of the runtime library at initialization of the application 
service provider apparatus. 



9. (Previously Presented): An apparatus comprising: 

storage medium having stored therein programming instructions designed to 
implement a dispatcher on the apparatus to: 

load a pre-determined version of a runtime library with multiple versions 
at initialization of the apparatus, the pre-determined version being the 
latest version, 

receive a request for service for an application during operation, 

determine, in response, whether the version of the runtime library 
required by the application is known to the dispatcher, and 

inquire with the latest version of the runtime library to learn of the 
required version of the runtime library if the version of the runtime 
library required by the application is not known to the dispatcher; and 

at least one processor coupled to the storage medium to execute the 
programming instructions. 



10. (Original): The apparatus of claim 9, wherein the dispatcher implemented by 
the programming instructions is further designed to receive from the latest version 
of the runtime library information on the required version of the runtime library, and 
in turn, cache the required version information. 



11. (Original): The apparatus of claim 10, wherein the dispatcher implemented 
by the programming instructions is further designed to route the request of service 
to the application to handle if the dispatcher is informed by the latest version of the 
runtime library that the required version of the runtime library is the latest version 
itself. 
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12. (Original): The apparatus of claim 10, wherein the dispatcher implemented 
by the programming instructions is further designed to determine whether the 
required version of the runtime library is loaded if the required version is an earlier 
version of the runtime library, and if the required earlier version of the runtime 
library is not loaded, load the required earlier version. 



13. (Original): The apparatus of claim 12, wherein the dispatcher implemented 
by the programming instructions is further designed to route the request of service 
to the application to handle if the required earlier version of the runtime library is 
already loaded or upon loading the required earlier version of the runtime library. 



14. (Original): The apparatus of claim 9, wherein the dispatcher implemented by 
the programming instructions is further designed to route the request for service to 
the application to handle if the required version of the runtime library is known to 
the dispatcher. 



15. (Original): The apparatus of claim 9, wherein the storage medium further 
having stored therein programming instructions to implement the plurality of 
versions of the runtime library. 

16. (Original): An apparatus comprising: 

storage medium having stored therein programming instructions designed to 
implement a version of an application service provision runtime library, including the 
ability to receive an inquiry to identify the version of the runtime library required by 
an application, and in response, responding with the required version; and 

at least one processor coupled to the storage medium to execute the 
programming instructions. 



17. (Previously Presented): A method comprising: 

accepting by a first resource consumer, first allocations of a first plurality of 
portions of a shared resource, and tracking first points in time the first allocations 
were last used; 

accepting by a second resource consumer, second allocations of a second 
plurality of portions of the shared resource, and tracking second points in time the 
second allocations were last used; 

conditionally requesting by a resource monitor, the first and second resource 
consumers to provide said tracked first and second points in time, and the first and 
second resource consumers responsively providing the tracked first and second 
points in time as requested; 

determining by the resource monitor which A if any A of the first and second 
allocations of the portions of the shared resource are to be released by the first and 
second resource consumers, and instructing the first and second resource 
consumers accordingly; and 
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releasing by the first and second resource consumers, selected ones of the 
first and second allocations as instructed. 



18. (Original): The method of claim 17, wherein the resource monitor 
conditionally requests the first and second resource consumers to provide said 
tracked first and second points in time when aggregated allocations of the shared 
resource reach a pre-determined threshold. 



19. (Previously Presented): The method of claim 17, wherein said determining 
by the resource monitor comprises ordering said provided first and second points in 
time, and selecting a number of the least recently used allocations to be released to 
bring an aggregate of the allocations to at most a predetermined threshold. 

20. (Previously Presented): In an apparatus having a shared resource 
consumer, a method of operation of the shared resource consumer, comprising: 

accepting allocations of a plurality of portions of a shared resource; 

tracking points in time the allocations were last used; 

receiving a request to provide the tracked points in time; 

in response, providing the tracked points in time as requested; 

receiving instructions to release selected ones of the allocations; and 

releasing the specified allocations as instructed. 

21 . (Original): The method of claim 20, wherein the apparatus is an application 
service provision apparatus, and the shared resource consumer is an application 
requiring application service provision runtime library support. 

22. (Original): The method of claim 20, wherein the apparatus is an application 
service provision apparatus, and the shared resource consumer is a function of an 
application service provision runtime library. 

23. (Currently Amended): In an apparatus comprising a shared resource 
monitor, a method of operation of the shared resource monitor, comprising: 

conditionally requesting a plurality of shared resource consumers to provide 
corresponding tracked plurality points in time, where corresponding plurality of 
portions of a shared resource allocated to the plurality of shared resource 
consumers were last used; and 

determining which, if any x of the plurality of allocations of the portions of the 
shared resource are to be released by the plurality of shared resource consumers, 
and instructing the plurality of shared resource consumers to release selected ones 
of the plurality of allocations accordingly. 
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24. (Currently Amended): The method of claim 23, wherein said conditionally 
request is made when aggregate allocations of the shared resource reach a pre- 
determined threshold. 



25. (Original): The method of claim 23, wherein said determining comprises 
ordering said provided plurality points in time, and selecting a sufficient number of 
the least recently used allocations to be released to bring the aggregate allocations 
to at most a predetermined threshold. 



26. (Original): The method of claim 23, wherein the resource monitor is a 
component of an application service provision apparatus. 

27. (Previously Presented): An apparatus comprising: 

storage medium having stored therein a plurality of programming instructions 
designed to implement a shared resource consumer, including the ability to: 

accept allocations of a plurality of portions of a shared resource, 

track points in time the allocations were last used, 

receive a request to provide the tracked points in time, 

provide, in response, the tracked points in time as requested, 

receive instructions to release selected ones of the allocations, and 

release the specified allocations as instructed; and 

at least one processor coupled to the storage medium to execute the 
programming instructions. 



28. (Original): The apparatus of claim 27, wherein the apparatus is an 
application service provision apparatus, and the shared resource consumer is an 
application requiring application service provision runtime library support. 

29. (Original): The apparatus of claim 27, wherein the apparatus is an 
application service provision apparatus, and the shared resource consumer is a 
function of an application service provision runtime library. 

30. (Previously Presented): An apparatus comprising: 

storage medium having stored therein a plurality of programming instructions 
designed to implement a shared resource monitor, including the abilities to: 

conditionally request a plurality of shared resource consumers to provide 
corresponding tracked plurality points in time, where corresponding 
plurality of portions of a shared resource allocated to the plurality of 
shared resource consumers were last used, and 
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determine which if any of the plurality of allocations of the portions of the 
shared resource are to be released by the plurality of shared resource 
consumers, and instruct the plurality of shared resource consumers to 
release selected ones of the plurality of allocations accordingly; and 

at least one processor coupled to the storage medium to execute the programming 
instructions. 



31 . (Currently Amended): The apparatus of claim 30, wherein said shared 
resource monitor is designed to make said conditionally request when aggregate 
allocations of the shared resource reach a pre-determined threshold. 

32. (Previously Presented): The apparatus of claim 30, wherein said shared 
resource monitor is designed to perform said determining by ordering said provided 
plurality points in time, and selecting a sufficient number of the least recently used 
allocations to be released to bring an aggregate of the allocations to at most a 
predetermined threshold. 

33. (Original): The apparatus of claim 30, wherein the apparatus is an 
application service provision apparatus, and the resource monitor is a component 
of said application service provision apparatus. 

Claims 34 - 37 (Canceled). 
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